
The info leak era on software exploitation 


Fermin J. Serna - @fjserna - fjserna@gmail.com 


Google Confidential and Proprietary 1 



Agenda 


Google 


• Background info on info leaks 

• What is an info leak? 

• Previous examples 

• Why were they not needed before? 

• Why are they needed now? 

• Info leak techniques: 

■ Heap overflows 

■ Type confusion vulnerabilities 

■ UAF and non virtual methods and other valuable operations (controlled read/ 
write, free() with controlled pointer, on demand vtables, ...) 

■ Application specific vulnerabilities: CVE-2012-0769 

■ Converting a use after free into an universal XSS 

• Envisioning the future of exploitation 
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Who is @fjserna? 


Google 


Fermin J. Serna - @fjserna - fjserna@gmail.com 
•Information Security Engineer at Google since Dec/2011 

•Previously Security Software Engineer at Microsoft - MSRC 

• Co-owner and main developer of EMET 

•Twitter troll at @fjserna 

•Writing exploits since 1999: http://zhodiac.hispahack.com 

• HPUX PARISC exploitation Phrack article 
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Background info on info leaks 
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What is an info leak? 


Google 


• Relevant quotes: 

• “An info leak is the consequence of exploiting a software vulnerability in 
order to disclose the layout or content of process/kernel memory”, Fermin 
J. Serna 

• “You do not find info leaks... you create them”, Halvar Flake at Immunity’s 
Infiltrate conference 2011 

• Info leaks are needed for reliable exploit development 

• They were sometimes needed even before ASLR was in place 

• Not only for ASLR bypass, as widely believed, which is a subset of 
reliable exploit development 
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Previous examples (incomplete list) Google 

• Wu-ftpd SITE EXEC bug - 7350wu.c - TESO 

• Format string bug for locating shellcode, value to overwrite... 

• IE - Pwn2own 2010 exploit - @WTFuzz 

• Heap overflow converted into an info leak 

• VUPEN has a nice example too at their blog 

• Comex’s Freetype jailbreakme-v3 

• Out of bounds DWORD read/write converted into an info leak 

• Duqu kernel exploit, HafeiLi’s AS3 object confusion, Skylined write4 
anywhere exploit, Chris Evan’s generate-id(), Stephen Fewer’s 
pwn2own 2011, ... 
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Why were they not needed before? 

• We were amateur exploit developers 

• Jumping into fixed stack addresses in the 2000 

• We were lazy 

• Heap spray 2 GB and jump to OxOcOcOcOc 

• Even when we became more skilled and less lazy there were 
generic ways to bypass some mitigations without an info leak 

• Jump into libc / ROP to disable NX/DEP 

• Non ASLR mappings to evade... guess??? ASLR 

• JIT spraying to evade ASLR & DEP 
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Why were they needed now? oogle 

• Reliable exploits, against latest OS bits, are the new hotness 

• Probably because there is lots of interest, and money, behind this 

• Security mitigations now forces the use of info leaks to bypass 
them 

• Mandatory ASLR in Windows 8, Mac OS X Lion, *nix/bsd/..., IOS, ... 

• Generic ways to bypass these mitigations are almost no longer 
possible in the latest OS bits 
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Let’s use an example 


Google 


int main(int argc, char **argv) { 
char buf[64]; 

_"try { 

memcpy(buf,argv[l] > atol(argv[2])); 

} except(EXCEPTION_CONTINUE_SEARCH) { 

} 

return 0; 


> 
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Let’s exploit the example... Google 


• No mitigations: overwrite return address of main() pointing to the 
predictable location of our shellcode 

• GS (canary cookies): Go beyond saved EIP and target SEH record 
on stack. Make SEH->handler point to our shellcode 

• GS & DEP: Same as above but return into libc / stack pivot & ROP 

• GS & DEP & SEHOP: Same as above but fake the SEH chain due 
to predictable stack base address 

• GS & DEP & SEHOP & ASLR: Pray or use an info leak for reliable 
exploitation 


Google Confidential and Proprietary 10 





Info leaking techniques 
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Info Leak techniques Google 


• Applicable to any target: 

■ With alloc/free primitives 

■ With specific object creation primitives 

■ With heap spraying capabilities (able to later read the heap spray) 

• Examples well researched: 

■ Web Browsers 

■ Any host of Flash (MS Office, pdf, ...) 

• Generally speaking “Any host of attacker controlled scripting” 

• But not limited... 

■ Example: alloc/free primitives on MS Office Excel BIFF record parsing 
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Info Leak techniques Google 


• Stack overflows: Partial overwrites 

• Heap overflows 

■ Overwriting the string.length field 

■ Overwriting the final NULL [w]char 

• UAF with non virtual methods and other valuable operations 

■ Member variables and write operations 

■ Member variables and read operations 

■ free() with a controlled pointer 

■ On demand function pointers or vtables 

• Type confusion 

• Converting a use after free into an universal XSS 

• Application specific vulnerabilities: CVE-2012-0769 
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Stack Overflows (Partial overwrites) 


Google 


• Continue of execution (CoE) and heap spraying is needed 

• Overwrite the target partially, leaving intact some original bytes 


• Return into an info leaking gadget within the page that will write 
“something” into our heap spray. 

■ Assuming at least one register contains something useful (i.e EBX) 


mov [ebp], ebx 
[■■■] 

retn XXX 4- determined by the CoE 




Stack based buffer 




Other variables 


A« 


V - 


Saved EBP 


■'V'" 


Saved EIP 


Function args 


0x10563480 0x7FE39823 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... 0x41414141 0x7FE34141 


Google Confidential and Proprietary 14 





















Heap Overflows (Overwriting the string.length field) ( oogle 


• Heap massaging is needed 

■ Place a JS string and an object after the heap buffer that will be overflowed 

• Overwrite the first four bytes of a JS string heap allocation 

■ First four bytes: String length 

■ Overwrite value: OxFFFFFFFF 


• Later on with JS you can read the entire address space (relative to 
your buffer) with: 


var content=str.substr(rel_address,rel_address+2) 


Heap based buffer 




JS string (var str) 


Object 


Size: 0x00000004 Blah 0x7F347690 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... Size: OxFFFFFFFF Blah 0x7F347690 
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Heap Overflows (Overwriting the final null [w]char) oogle 


• Heap massaging is needed 

■ Place a string and an object after the heap buffer that will be overflowed 


• Overwrite the last [w]char of a string heap allocation 

• Later on with JS you can read passed the string boundaries: 

var content=elem.getAttribute( ‘title’) 


V V \ 


Heap based buffer 

Title attribute string 

Object 

^ J 

k_ J 

k_, 


Blah\0\0 

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... AAAAAA 


0x7F347690 

0x7F347690 
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Use after free 


Google 


• Applicable also to uninitialized variables once you got the pointer 
pointing to your fake object. 

• We are not looking for these “awesome” type of crashes: 

mov ecx, [eax] <- eax points to the object and the vtable_ptr gets dereferenced 
call dword ptr [ecx+offset] <- call a virtual function of the object 


• We are looking for some other “interesting” type of scenarios: 

push ecx 4 - push object pointer to the stack 

call module!Object::NonvirtualFunction 


So we do not AV when calling into a virtual function and more 
interesting things can happen later on... 
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Use after free (member variables and read ops) oogle 


• Read some value from a controlled place in memory 

■ Hopefully getting it back to the attacker somehow (JS?) 


class cyberpompeii { 
private: 

void * ptr; 4- attacker will control this once he gets the free chunk 
public: 

DWORD f() { 

return *(DWORD *)ptr; 

} 

}; 
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Use after free (member variables and write ops) oogle 


• Write some value to a controlled place in memory 

• Strategy: 

■ Write into 0x41414141 hoping it writes into our heap spray 

■ Calculate the offset to the initial of the string by reading the JS string and locating 
the new value 

■ Write to the string.length of the JS string. 

■ Use the substring trick previously mentioned 

class cyberpompeii { 
private: 

void * ptr; <- attacker will control this once he gets the free chunk 
public: 
void f() { 

*(DWORD *)ptr|=0x80000000; 

} 

}; 
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Use after free (free() with a controlled pointer) 


Google 


• Heap massaging and predictable layout (some heap 
implementations) required. 

• Strategy: 

■ Spray JS strings of size X 

■ Force the free of one of these strings through the vulnerability 

■ Force the allocation of hundreds of objects of size X 

• One of them will get the forced freed string 

■ Read the vtable pointer from the JS reference of the freed string 
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Use after free (free() with a controlled pointer) 


Google 


class cyberpompeii { 
private: 

void * ptr; 
public: 
void f() { 
free(ptr); 

} 

}; 


Freed object with controlled 
contents 




AAAA II vtable_ptr 
[■■■] 

0x0c0c4560 II ptr 
[■■■] 


Stepl: 

Use the vulnerability to force 
the free of a JS string 


Step2: 

Use a primitive to allocate X 
objects of the same size Y 


Step3: 

Read the vtable ptr from 
JS (reference to the string) 


String spray 




AAAAAAAAAAAAAAAAA 



AAAAAAAAAAAAAAAAA 



AAAAAAAAAAAAAAAAA 

AAAAAAAAAAAAAAAAA 

0x7f3E4560 AAAAAAAAA 


AAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAAA 


AAAAAAAAAAAAAAAAA 
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Use after free (On demand [function] ptrs | vtables) ( oogle 


• Assuming you get the freed chunk via a JS readable string 

• Find a non virtual function, exercisable via your primitives, that will 
write to a member variable a function pointer, an on demand vtable 
(or still interesting a heap address) 

• Read ptr back from JS string that got the object chunk 


class cyberpompeii { 


Memory chGta£adbimed by a string 


private: 




AAAAAAAAAAAAAA 


:\ 


void * ptr; 


[■■■] 

AAAAA 


public: 


void f() { 

HMODULE dll=LoadLibrary(“kernel32.dll”); 
ptr=GetProcAddress(dll/’WinExec”); 


0x7F345678 


AAAAAAAAAAAA 





r 
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Type confusion 



• Replace the freed object memory chunk (size X) with a different 
object type of same size X. 

■ Virtual call friendly, since the vtable_ptr will point to a valid place, but different 
than expected 

■ The virtual function called must have the same number of arguments for CoE 

• Does this new virtual function perform any of the previously mentioned, and 
useful, operations? And does not crash the application? © 

class original_object { class replaced_object { 

private: private: 


void * blahhh; 


void * ptr; 


public: 


public: 


virtual void foo() { 


return - 1 ; 

} 


virtual void bar() { 

HMODULE dll=LoadLibrary(“kernel32.dll”) 
ptr=GetProcAddress(dll/’WinExec”); 


}; 


} 
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Use after free converted into an UXSS 


Google 


• If everything fails we still have application specific attacks 

■ More to come later on Flash CVE-2012-0769 

• Not an info leak but cool scenario: 

■ Use after free on an object derived from CEIement (with rare size such as table, 
script, ... ) bound to a JS variable on page X 

■ Page X hosts hundreds of iframes pointing to the attacked domain Y (same 
process on some browsers) 

■ One of the CEIement of domain Y gets the freed chunk 

■ Page X can inject other JS code on domain Y bypassing the same origin 
policy, through the reference to the original, and freed, object. 

• Sounds crazy? 

■ It works, but not reliably. 
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Use after free converted into an UXSS 


Google 



Attacker page 


var elem = 




Stepl: Attacker triggers the vuln: free an object (size X) 
while holding a reference through elem 



Step 2: Attacker sprays with iframes hoping one of them 
will allocate this freed memory with a CEIement 


At this point Attacker page holds a reference (elem) to a 
CEIement on target frame 


Step 3: Use insertAdjacentElement, appenChild, 
innerHTML, ... to insert a script tag with attacker JS in the 
target frame 



Google Confidential and Proprietary 25 





































Demo time! 


Google 


• Target: IE9/Win7 

■ Using a patched vulnerability...CVE-2012-1889 

■ MSXML un-initialized stack variable 


• Using one of the techniques mentioned before... 


• Do not ask for the exploit or further information 

■ I will not share weaponized code or information for exploiting this vulnerability with 
anyone! 
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CVE-2012-0769: the case of the 
perfect info leak 
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The vulnerability oogle 

• Universal info leak 

• Already fixed on Adobe’s Flash in March/2012 

• 99% user computers according to Adobe 

• Affects browsers, Office, Acrobat, ... 

• Unlikely findable through bit flipping fuzzing. But, Likely findable 
through AS3 API fuzzing 

• Got an email requesting price for the next one (6 figures he/she 
said) 

• Detailed doc at http://zhodiac.hispahack.com 
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The vulnerability (CVE-2012-0769) 


Google 


public function histogram(hRect:Rectangle = null):Vector.<Vector.<Number» 


Flash Heap 


i 


BitmapData buffer 

Rectangle 


V 



Figure 1 - Normal Use case of BitmapData.histogram!) Figure 2 - Out of bounds use case of BitmapData.histogram!) 
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The exploit (CVE-2012-0769) 



• Convert histogram to actual leaked data 


function find_item(histogram:Vector.<Number>):Number { 


var i:uint; 


for(i=0;i<histogram.length;i++) { 


if (histogram[i]==l) return i; 


> 


return 0; 


} 


[...] 

memory=bd.histogram(new Rectangle(-0x200,0,1,1)); 
data=(find_item(memory[3])<<24) + 
(find_item(memory[0])<<16) + 
(find_item(memory[l])<<8) + 
(find_item(memory[2])); 
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The exploit (CVE-2012-0769) Google 

• Convert relative info leak to absolute infoleak 

• Need to perform some heap feng shui on flash 

• Defragment the Flash heap 

• Allocate BitmapData buffer 

• Allocate same size buffer 

• Trigger Garbage Collector heuristic 

• Read Next pointer of freed block 
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The exploit (CVE-2012-0769) Google 

Common Flash heap state 



Figure 3 - Common Flash custom heap layout 


Google Confidential and Proprietary 32 









The exploit (CVE-2012-0769) Google 

Defragmented heap 




Figure 4 - Flash heap layout after defragmentation 
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The exploit (CVE-2012-0769) 


After allocating the BitmapData buffer 




Figure 5 - Flash heap layout after defragmentation and BitmapData buffer allocation 


Google 
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The exploit (CVE-2012-0769) 


After allocating the same size blocks 



Figure 6- Preparing the soon to be freed linked list 


Google 
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The exploit (CVE-2012-0769) Google 


After triggering GC heuristics 



Figure 7 - Flash heap layout after Garbage Collection 
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The exploit (CVE-2012-0769) 

• Leak the next pointer of the freed block 

• bitmap_buffer_addr=leaked_ptr-(2*0x108) 

• 0x108 = 0x100 + sizeof(flash_heap_entry) 

• 0x100 = size use for BitmapData 

• Once we have bitmap_buffer_addr we can read anywhere in the 
virtual space with: 



data=process_vectors( 

bd.histogram (new Rectangle(X-bitmap_buffer_addr,0,1,1)) 


); 
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The exploit (CVE-2012-0769) on Windows Google 

Target USER_SHARE_DATA (0x7FFE0000) 

X86 


7ffe0300 

776370b0 ntdll!KiFastSystemCall Read this address and 

subtract 

an OS specific offset 

7ffe0304 

776370b4 ntdll!KiFastSYStemCallRet 

7ffe0308 

00000000 

7ffe030c 

00000000 

7ffe0310 

00000000 

7ffe0314 

00000000 

7ffe0318 

00000000 

7ffe031c 

00000000 


Win7 Spl 

0:016> ? ntdllj^ - ntdll 

Evaluate expression: 230392 = 000470b0 OS specific offset to 

subtract in order to get ntdll.dll imageb a se. 

0 : 016 > 
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The exploit (CVE-2012-0769) on Windows oogle 


X64 


f}0000000'7ffe0340 
00000000'7ffe0344 
00000000'7ffe0348 
00000000'7ffe034c 
00000000'7ffe0350 
00000000'7ffe0354 


77b79e69 ntdll32!LdrlnitializeThunk 
77b50124 ntdll32!RiUserExceptionDispatcher 
77b50028 ntdll32!RiUserApcDispatcher 
77b500dc ntdll32!RiUserCallbackDispatcher 
77bdfc24 ntdll32!LdrHotPatchRoutine 
77b726dl 


ntdll32!ExpInterlockedPopEntrySListFault 
00000000'7ffe0358 77b7269b 


ntdll32!ExpInterlockedPopEntrySListResume 

00000000'7ffe035c 77b726d3 ntdll32!ExpInterlockedPopEntrySListEnd 

00000000 v 7ffe0360 77b501b4 ntdll32!RtlUserThreadStart 

00000000 x 7ffe0364 77be35da 


ntdll32!RtlpQueryProcessDebugInformationRemote 
00000000 v 7ffe0368 77b97111 ntdll32!EtwpNotificationThread 

00000000'7ffe036c 77b40000 ntdll32!'string’ <PERF> (ntdll32+0x0) 
base address of ntdll32.dll 
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The exploit (CVE-2012-0769) on Firefox oogle 



Mozilla's Firefox 10 (Win7 SP1 64bits) running vulnerable Flash version 
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The exploit (CVE-2012-0769) on IE 


Google 





<3 C:\Uten\Fef\Cteslctop\Tesl— x L 


ft ★ o 


[Windows 7] My heap address is 0xb49b758 and ntdll base is 
0x77dd0000 


o- 


Would you like to make Internet Explorer your default browser? 


Yes No 


T 


Microsoft's Internet Explorer 9 (Win7 SP1 64bits) running vulnerable Flash version 
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The exploit (CVE-2012-0769) on Chrome oogle 



Google's Chrome 17 (Win7 SP1 64bits) running vulnerable Flash version 


Google Confidential and Proprietary 42 















Envisioning the future of exploitation 
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The future of exploitation as I see it... 


Google 


• It will get harder, weak exploit developers will be left behind, 
profitable profession if you can live to expectations. 

• It will require X number of bugs to reliably exploit something: 

• The original vulnerability 

• The info leak to locate the heap (X64 only). 

• No more heap spraying. 

• The info leak to build your ROP in order to bypass DEP 

• The sandbox escape vulnerability OR the EoP vulnerability 

• In future... imagine when applications have their own transparent VM... 

• The VM escape vulnerability to access interesting data on other VM 
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@fjserna - fjserna@gmail.com 

Q&A 
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